IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCES 



In re Application of; 



Saulpaugh, et al. 



-^^''erialNo. 09/653,215 




Filed: August 31, 2000 

For: METHOD AND APPARATUS 
TO OBTAIN SERVICE 
CAPABILITY CREDENTIALS 



Group Art Unit: 2131 

Examiner: Chen, Shin Hon 

Atty. Dkt. No.: 5181-70400 
P5200 



CERTIFICATE OF MAILING 
37CF.R. § 1.8 

I hereby certify that this correspondence is being deposited with 
the U.S. Postal Service with sufficient postage as First Class 
Mail in an envelope addressed to: Commissioner for Patents, 
P.O. Box 1450, Alexandria, VA 22313-1450, on the date 
indicated below: 

Robert C. Kowert 



Name of Registered Representative 



July 29. 2005 
Date 




Signature 



APPEAL BRIEF 



Mail Stop Appeal Brief - Patents 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Sir/Madam: 
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I. REAL PARTY IN INTEREST 

As evidenced by the assignment recorded at Reel/Frame 011070/0129, the subject 
application is owned by Sun Microsystems, Inc., a corporation organized and existing 
under and by virtue of the laws of the State of Delaware, and now having its principal 
place of business at 4150 Network Circle, Santa Clara, CA 95054. 

II. RELATED APPEALS AND INTERFERENCES 

No other appeals, interferences or judicial proceedings are known which would be 
related to, directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 

IIL STATUS OF CLAIMS 

Claims 1-47 stand finally rejected. The rejection of claims 1-47 is being 
appealed. A copy of claims 1-47 as currently pending is included in the Claims 
Appendix herein below. 

IV. STATUS OF AMENDMENTS 

An after-final amendment, submitted via Facsimile on July 28, 2005, amends 
claims 33 - 47 to recite a tangible computer accessible medium rather than a carrier 
medium. The Examiner has not indicated whether this amendment will be entered. The 
Claims Appendix included herewith reflects the state of the claims prior to this 
amendment. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Independent claim 1 is directed toward a method for accessing a service in a 
distributed computing environment in which a client locates a service within the 
distributed computing environment and requests a capability credential to allow the client 
access to a portion of the service's capabilities. In distributed computing environments 
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according to some embodiments, service discovery protocols allow client to search for 
and locate services of varies types. For example, clients may send search messages or 
queries using data representation languages, such as XML, v^hich may include search 
criteria, such as desired service name and/or service type. Service providers may respond 
to search queries by providing service advertisements or by providing information to 
allow client to access stored advertisements, such as via a URI or other address. A 
service provider may compare the client's search criteria against service advertisements 
to find advertisements that match the search criteria. Additionally, clients may search 
advertisements in spaces or space services. The advertisements may use data 
representation languages and may include information, such as an address or interface, 
allowing client to obtain credentials necessary for access the service. A service 
advertisement may either be a complete advertisement including schema information 
regarding messages usable to access the service, or a protected (or secure) advertisement 
not including such schema information. See, e.g., FIGs. 4, 6- 9, 12, 14-16, 18, 20, 22, 24, 
26a-b, 28, 29 and 41-43; page 25, line 27 - page 26, line 13; page 27, lines 22 - 30; page 
28, line 13 - page 29, line 16; page 29, line 26 - page 30, line 23; page 54, line 3 - 55, 
line 20; page 64, line 18 - page 65, line 20; page 90, line 27 - page 91, line 12; page 92, 
lines 16 - 29; page 106, lines 12-30; page 107, lines 3 - 28; page 108, lines 11-26; page 
1 1 1, line 16 - page 1 12, line 6; page 1 14, lines 13-23. 

A cUent may select a service and request a capability credential by sending (e.g., 
to a URI specified in a corresponding service advertisement) a capability credential 
request message. The advertisement may include the address of an appropriate 
authentication service providing capability credentials. In some embodiments, the 
advertisement may include a schema or other information regarding messages to access 
the service. For instance, a service's message set may be defined using a data 
representation language schema, such as an XML schema, that defines each message 
format using typed tags. As part of requesting a capability credential, the client may 
indicate a set of desired capabilities. For example, a client may present the service a set 
of desired capabilities in the form of a secure advertisement. See, e.g., FIGs. 4, 6- 9, 12, 
14-16, 18, 20, 22, 24, 26a-b, 28, 29 and 41-43; page 29, line 26 - page 30, line 23; page 
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55, lines 8-20; page 93, lines 1 - 24; page 102, lines 6 - 25; page 103, line 24 - page 104, 
line 17; page 107, lines 12-30. 



Additionally, the client receives a capability credential indicating that the client 
has the right to use the portion of the service's capabilities. As noted above, a client 
requests a capability credential using a capability credential request message. A 
credential request message may be sent to an authentication service using a URI specified 
in a service's advertisement. The capability credential may be generated according to 
capabilities requested by the client and/or the client's level of authorization. 
Additionally, if the client received a protected service advertisement in response to its 
original search query, the client may also use the capability credential to obtain a 
complete advertisement. See, e.g., FIGs. 20, 22, 26a-b and 41-43; page 13, lines 21 - 30; 
page 14, line 29 - page 15, line 13; page 38, lines 17-29; page 59, lines 16-25; page 60, 
lines 7-14; page 66, lines 16 - 26; page 75, lines 23 - 26; page 91, lines 1-12; page 104, 
line 21 - page 106, line 7. 

The client uses the capability credential to access portions of the service's 
capabilities. For instance, the client may use both the capability credential and the 
service advertisement to create a message gate for sending messages according to a 
schema in the service advertisement to access and use the service. In some embodiments, 
the gate may include the capability credential in each message to that the service can 
authenticate each message from the client. See, e.g., FIGs. 20, 22, 26a-b and 41-43; page 
30, line 27 - page 31, line 38, line 5; page 36, lines 5-12; page 45, lines 1 - 14; page 54, 
lines 13 - 21; page 75, lines 9-17; page 91, line 14 - page 92, line 7; page 98, line 23 - 
page 99, line 14. 

Independent claim 17 is directed toward a client device that includes a connection 
to a distributed computing environment and an interface coupled to the connection that is 
configured to locate a service within the distributed computing environment. The 
interface of the client device of claim 17 is configured to request a capability credential 
over the connection for a set of desired capabilities to allow a client on the client device 



09/653^15 (5181-70400/P5200) 



4 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



access to a portion of the service's capabilities. The client device interface is also 
configured to receive the capability credential over the connection. As with the 
capability credential described above regarding claim 1, the capability credential of claim 
17 indicates that the client has the right to use the portion of the service's capabilities. 
The interface is further configured to use the capability credential to access the portion of 
the service's capabilities. For more details regarding locating services, obtaining and 
using both service advertisement and capability credentials, please see the above 
discussion of independent claim 1 . 

Lidependent claim 33 is directed toward a medium including program instructions 
that are computer-executable on a client device to implement the method described above 
regarding claim 1 . Please refer to the discussion of independent claim 1 above for more 
details. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 1-7, 9-13, 16-23, 25-29, 31-39, 41-45 and 47 stand finally rejected 
under 35 U.S.C. § 102(a) as being anticipated by Czerwinski, et al., "An Architecture for 
a Secure Service Discovery Service" (hereinafter "Czerwinski"). 

2. Claims 8, 24 and 40 stand finally rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Czerwinski in view of Vacon et al. (U.S. Patent 5,227,778, 
hereinafter "Vacon"). 

3. Claims 14, 15, 30 and 46 stand finally rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Czerwinski in view of Johnson et al. (U.S. Patent 5,560,008, 
hereinafter "Johnson"). 

VIL ARGUMENT 

First Ground of Rejection 
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Claims 1-7, 9-13, 16-23, 25-29, 31-39, 41-45 and 47 stand finally rejected under 
35 U.S.C. § 102(a) as being anticipated by Czerwinski. Appellants traverse this rejection 
for at least the following reasons. Different groups of claims are addressed under their 
respective subheadings. 

Claims 1, 10-13. 17. 26-29, 33 and 42-45 : 

Regarding claim 1, Czerwinski fails to teach requesting a capability credential to 
allow the client to access a portion of the first service's capabiUties, wherein said 
requesting a capability credential comprises the client indicating a set of desired 
capabilities . The Examiner cites passages in Czerwinski (Sections 3.3 and 3.4) that 
discuss the certificate authority and the capability manager of a Service Discovery 
Service (SDS). Czerwinski describes a secure Service Discovery Service (SDS) wherein 
a client requests a capability credential from a capability manager. However, an SDS 
client does not indicate a set of desired capabilities when requesting a capability 
credential. Instead, each service in the SDS system contacts the capability manager, and 
"specifies an access control list" including a list of principals, such as clients, allowed to 
access the service's description (Czerwinski, section 3.4, paragraph 3). It is only after 
obtaining a capability credential from the CM that a client contacts an SDS Server to 
locate one or more services. The SDS server returns services that match the client's 
query (Czerwinski, section 3.1, paragraph 5). The client presents the capability credential 
to the SDS server and the server only retums services to which the client has access based 
upon the capability credential obtained from the Capability Manager. Thus, a client is 
granted access to all or none of a service's features based on whether that client is 
included in the service's access control list. In other words, SDS services specify which 
clients can have access to their respective services, but an SDS client does not indicate a 
set of desired capabiUties when requesting a capability credential. The capability 
manager gives the client a capability credential that informs the SDS server of which 
services the client is able to access. 

In response to the above argument, the Examiner states, "Czerwinski discloses a 
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client contacts the CA and specifies the principal's certificate that it is interested in," 
again citing section 3.3 of Czerwinski. However, a principal's certificate in 
Czerwinski does not indicate a set of desired capabilities. Instead, a principal's 
certificate is a "public-key certificate that can be used to prove the component's identity 
to all other components" (Czerwinski, section 2.4, paragraph 2). Thus, the certificates to 
which the Examiner is referring provide authentication within Czerwinski's system and 
do not have anything to do with a client indicating a set of desired capabilities. 
Czerwinski teaches that his system uses certificates "to authenticate the bindings between 
principals and their public keys (i.e., verifying the digital signatures used to establish the 
identities of SDS components)" (Czerwinski, section 3.3, paragraph 1). 

Czerwinski's client requesting a principal's certificate is clearly different from 
requesting a capability credential where the client indicates a set of desired capabilities, 
as recited in claim 1. As noted above, Czerwinski's certificates provide authentication, 
not any indication of a desired set of capabilities. Furthermore, the Examiner's cited 
passage states that Czerwinski's Certificate Authority provides a principal's 
certificate to a client^ and thus, even if Czerwinski's certificates did indicate a set of 
desired capabilities, which they clearly don't, the Examiner's argument still would 
not provide for a client indicatin£ a set of desired capabilities. 

Claims 2, 18 and 34 : 

Regarding claim 2, the Examiner asserts that Czerwinski teaches that requesting a 
capability credential comprises the client sending a capabihty credential request message, 
wherein said capabihty credential request message comprises an identification of said 
first service and an indication of the set of desired capabilities. The Examiner's 
interpretation of Czerwinski is incorrect. In fact, Czerwinski fails to disclose a capabihty 
credential request message that comprises an identification of the first service. The 
Examiner's cited passages (sections 3.3 and 3.4) disclose how a client contacts a 
capability manager to obtain the client's capabilities, but neither of these passages 
describes a capability credential request message that comprises an indication of a 
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service. In contrast, Czerwinski states that SDS services provide an access control list 
including a list of principals, such as cUents, allowed to access the service's description 
(Czerwinski, section 3.4, paragraph 3). Czerwinski further states that the capability 
manager "then generates the appropriate capabiUties and saves them for later distribution 
to the clients" (Czerwinski, section 3.4, paragraph 3). Thus, rather than a cUent sending a 
capability credential request message that comprises an identification of the service, 
Czerwinski teaches that the identity of the client is matched against access control lists to 
determine which services the client is allowed to discover. 

Additionally, Czerwinski fails to teach that the capability credential request 
message comprises an indication of the set of desired capabilities . As argued above 
regarding claim 1, Czerwinski' s SDS clients do not indicate a desired set of capabilities 
when requesting a capability credential. Instead, they obtain a capability credential that 
allows the SDS server to retum only those services that have specifically granted the 
client access (Czerwinski, section 3.1, paragraph 5). Therefore, any capability credential 
request message in SDS would not, and could not, comprise an indication of a client's set 
of desired capabilities. 

In response the above arguments, the Examiner states, "Czersvinski discloses the 
first service, which is the SDS service, and the set of desired capabilities" citing section 
3.1, paragraph 5, and section 6.1 of Czerwinski. However, section 3.1, paragraph 5 
describes how a client submits a query to the SDS service along with the client 
capabilities to search for "service descriptions that both match the query and are 
accessible to the user." Czerwinski's SDS service does not provide capability credentials 
to clients. Instead, as noted above, Czerwdnski's system includes a capability manager 
that distributes capabilities. A client submitting a query to an SDS service does not 
involve a capability credential request message. Section 6.1 of Czerwinski briefly 
describes the imique service names of both the Internet Domain Naming Service and 
Globe. However, this cited passage makes no mention of capability credentials, 
capability credential request messages, nor any indication of a set of desired capabilities. 
In fact, section 6.1 of Czerwinski is completely irrelevant to a capability credential 
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request message comprising an identification of said first service and an indication of the 
set of desired capabilities, as recited in claim 2. 

Claims 3. 19 and 35 : 

In regard to claim 3, contrary to the Examiner's contention, Czerwinski fails to 
teach that the identification of said first service comprises a Universal Unique Identifier 
(UUID). The Examiner cites section 6.1 of Czerwinski, but this passage only states that a 
different discovery service. Globe, uses unique object identifiers to identify services. 
Section 6.1 clearly fails to disclose a capability credential request message comprising an 
identification of a service wherein that identification of the service comprises a UUID. In 
contrast, as shown above regarding claim 2, Czerwinski teaches that clients do not 
identify a service when requesting a capability credential. Hence, any use of UUIDs 
(note that Czerwinski does not even mention UUDDs) or "Globe unique object 
identifiers", in SDS would not involve including a UUID as part of an identification of a 
service in a capability credential request message. Also, the Globe unique object 
identifiers in Czerwinski are not described as UUIDs. Czerwinski clearly fails to teach 
that the identification of the first service comprises a Universal Unique Identifier 
(UUID). 

In response to the above argument, the Examiner states, "Czerwinski discloses 
that the SDS is connected to the client through ARMI, which commonly uses UUID to 
identify the service" citing section 3.1, paragraph 5 and section 3.5.3 of Czerwinski. 
However, as noted above, a client in Czerwinski' s system does not send a capability 
credential request message to an SDS service. Neither of the cited passages mention 
anything about, nor have anything to do with, capability credential request messages. 
Whether or not ARMI uses UUIDs (the Examiner has provided no evidence in this 
regard) to identify services for other purposes does not disclose anything about the 
contents of a capability credential request message. The Examiner seems to be 
completely ignoring this limitation of Appellant's claims. 
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Furthermore, the Examiner has not established a proper case of anticipation 
because the teachings relied on by the Examiner are from separate works. 

Anticipation requires the presence in a single prior art reference disclosure of each and 
every element of the claimed invention, arranged as in the claim . Lindemann 
Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 
1984). The identical invention must be shown in as complete detail as is contained in the 
claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
Although all the teachings cited by the Examiner are discussed in a single reference, the 
teachings are not part of a single method. For example, the portion of Czerwinski cited 
by the Examiner at section 6.1 is part of Czerwinski' s discussion of related work and 
pertains to a different service discovery system (Globe) than the portion of Czerwinski 
cited by the Examiner at sections 3.3 and 3.4. To anticipate the claimed invention, 
Czerwinski must teach a single method that is identical to Appellants' claimed invention. 
Otherwise, Czerwinski cannot be said to teach the identical invention arranged as in 
Appellants' claims . Moreover, as discussed above, no combination of teachings in 
Czerwinski teaches Appellants' claimed invention. 

Claims 4. 20 and 36 : 

Regarding claim 4, contrary to the Examiner's assertion, Czerwinski fails to 
disclose that said capabilitv credential request message is formatted in extensible 
Markup Language (XML) . The Examiner cites section 3.1 of Czerwinski. However, this 
passage only describes how a cUent uses XML to build a service query that is matched 
against various service descriptions by the SDS server. As noted above, an SDS client 
must already have a capability credential obtained from Czerwinski 's capability manager 
prior to querying an SDS server. Furthermore, Czerwinski only states that "[s]ervice 
descriptions and queries are specified in extensible Markup Language (XML)" 
(Czerwinski, section 1, paragraph 5). Neither service descriptions nor service queries in 
SDS are capability credential request messages. Czerwinski fails to mention anything 
about using XML to format a capability credential request message. In fact, Czerwinski 
fails to describe the formatting of a capability credential request message at all. Thus, 
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Czerwinski clearly fails to disclose wherein said capability credential request message is 
formatted in extensible Markup Language (XML). 

In the Response to Arguments section of the Final Office Action, the Examiner 
response to the above argxmient by stating, "since the SDS query is in XML format and 
the query contains capabilities . . . [t]herefore, the capabilities credential request message 
and the credential are commxmicated in XML format in order to make it easier to 
communicate." This argument by the Examiner is clearly flawed. Firstly, the very fact 
that an SDS query includes capabilities, as admitted by the Examiner, demonstrates that 
the SDS query cannot be a capability credential request message. Secondly, just because 
an SDS query is formatted in XML does not imply that anything else, including a 
capability credential request message, is formatted in XML. As noted above, Czerwinski 
fails to teach anything regarding the format of a capability credential request message. 
Thirdly, the Examiner is incorrect that a capability credential in SDS is communicated in 
XML format. Czerwinski teaches that "capabilities, like certificates, are securely 
associated with a single principal, and only the clients possessing the appropriate private 
key can use them" (Czerwinski, section 3.4, paragraph 3). Czerwinski' s capabilities are 
clearly encrypted and not formatted in XML. The Examiner's argument amoimts to 
nothing more than merely speculation and unsubstantiated conclusion unsupported by 
any teaching or suggestion from Czerwinski. 

In the Advisory Action, the Examiner further responds to the above argument by 
stating, "since XML is a well known data representation language, it would be [a] design 
choice to apply similar data representation languages." Appellants do not see the 
relevance of the Examiner's statement. Appellants' claims do not recite anything about 
applying similar data representation languages. Additionally, the Examiner's opinions 
regarding whether or not XML is a well-known data representation language and 
regarding possible or potential design choices have no bearing on a § 102(a) rejection 
based on anticipation. Without some clear disclosure by Czerwinski regarding a 
capability credential request message formatted in XML, Czerwinski cannot be said to 
anticipate Appellants' claim 4. 
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Claims 5. 9. 21. 25, 37 and 41 : 



Regarding claim 5, contrary to the Examiner's assertion, Czerwinski fails to teach 
that said indication of the set of desired capabilities comprises an indication of said 
advertisement . Specifically, as noted above, capability credential request messages in 
SDS do not include an indication of desired capabilities. Furthermore, Czerwinski fails 
to disclose that the indication of the set of desired capabilities comprised in a capability 
credential request message comprises an indication of an advertisement for the first 
service. The Examiner's cited passages (Czerv^inski, sections 3.1, 3.3, and 34) describe 
SDS servers, certificate authority and capability managers. However, when requesting 
capability credentials, SDS clients do not include any indication of a desired set of 
service capabilities, as noted above. Furthermore, SDS clients do not include an 
indication of an advertisement for a service as part of an indication of a set of desired 
capabilities, when querying an SDS service. Instead, clients include desired capabilities 
in queries to locate service advertisements (e.g. service descriptions) (Czerwinski, section 
3.1, paragraph 5). 

In response to appellants argument above, the Examiner states, without citing any 
particular portion of Czerwinski, "Czerwinski discloses the advertisement domain 
contains the service announcements and contact information for the capability manager 
and certificate authority that are indication[s] of the desired capabilities". The Examiner 
is presumably referring to Czervdnski's teachings regarding domain advertisements, as 
described in section 3.1, paragraph 1. However, Czerwinski specifically states that each 
server sends domain advertisements that are authenticated messages "containing a list of 
domains that [the server] is responsible for" (Czerwinski, section 3.1, paragraph 1). Plus, 
contact information for a service is not an indication of desired capabilities. Instead, 
contact information merely provides a means of addressing (e.g. sending messages to) an 
entity in Czerwinski 's system. Thus, the domain advertisements do not include any 
indications of desired capabilities. Moreover, the Examiner appears to be arguing that 
Czerwinski's domain advertisements include indications of desired capabilities, which, 
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even if true, which it is not, would be completely the opposite of what is recited in 
Appellants' claim. Claim 5 recites, in part, wherein the indication of the set of desired 
capabilities comprises an indication of the advertisement. Thus, the Examiner's 
contention that a domain advertisement includes indications of desired capabilities does 
not address appellants' argument that Czerwinski fails to teach that an indication of the 
set of desired capabilities includes an indication of the advertisement. 

Claims 6. 22 and 38 : 

Regarding claim 6, contrary to the Examiner's assertion, Czervdnski fails to teach 
wherein said indication of said advertisement is said advertisement itself The remarks 
above regarding claim 5 apply to claim 6 as well. Additionally, Czerwinski fails to teach 
including an advertisement for a service in a capability credential request message, as 
described previously. The Examiner cites passages (Czerwinski, sections 3.1, 3.3, and 
3.4) that describe SDS servers, capability mangers, and certificate authority. However, 
nowhere in the Examiner's cited passages, nor anywhere else, does Czerv^nski describe 
including an advertisement for a service in a capability credential request message. In 
contrast, Czerwinski teaches that a capability manager receives access control lists from 
services that include lists of principals that are allowed to access a service (Czerwinski, 
section 3.4). An SDS chent does not include any indication of an advertisement for a 
service in a capability credential request message and certainly does not include the 
advertisement itself as the indication of the advertisement in a capability credential 
request message. Instead, an SDS client receives from the capability manager a 
credential that is presented to a SDS server by the client. The SDS server then uses that 
credential to return only services that the client is allowed to access. (See Czerwinski, 
section 3.1, paragraph 5). Thus, Czerwinski clearly fails to teach that said indication of 
said advertisement is said advertisement itself Appellants note that the Examiner has 
never provided any rebuttal to this argument. 

Claims 7, 23 and 39 : 

Regarding claim 7, the Examiner contends that Czerwinski discloses a method 
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including wherein said indication of said advertisement is a Uniform Resource Identifier 
(URI) to said advertisement. The Examiner's interpretation of Czerwinski is incorrect. 
The Examiner cites sections 3.1 and 3.4 of Czerwinski that describes the workings of 
SDS servers and SDS capability managers. Specifically the Examiner is relying upon the 
fact that in SDS "a capability proves the client is on ACL [access control list] by 
embedding the client' s principal name and the service name" combined with 
Czerwinski's disclosure regarding the Globe services us globe unique object identifier. 
However, the teachings in Czerwinski that the Examiner is relying upon have nothing to 
do with a capability credential request message. In fact, the cited passage of Czerwinski 
does not mention anything regarding a capability credential request message nor does it 
describe using a URI to an advertisement as an indication of the advertisement in a 
capability credential request message. In contrast, Czerwinski teaches that a capability 
manager receives access control lists fi*om services that include lists of principals that are 
allowed to access a service (Czerwinski, section 3.4). The service advertisements in SDS 
are sent by individual services and are collected by SDS servers to compare against client 
queries (Czerwinski, section 2.3). Nowhere does Czerwinski teach that a client includes 
a URI to an advertisement as an indication of the advertisement in a capability credential 
request message. 

Furthermore, the Examiner has not established a proper case of anticipation 
because the teachings relied on by the Examiner are from separate works. 

Anticipation requires the presence in a single prior art reference disclosure of each and 
every element of the claimed invention, arranged as in the claim . Lindemann 
Maschinenfabrik GmbHv, American Hoist & Derrick Co,, 221 USPQ 481, 485 (Fed. Cir. 
1984). The identical invention must be shown in as complete detail as is contained in the 
claims. Richardson v. Suzuki Motor Co,, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
Although all the teachings cited by the Examiner are discussed in a single reference, the 
teachings are not part of a single method. For example, the portion of Czerwinski cited 
by the Examiner at section 6.1 pertains to a different service discovery system (DNS) 
than the portion of Czerwinski cited by the Examiner at sections 3.3 and 3.4. To 
anticipate the claimed invention, Czerwinski must teach a single method that is identical 



09/653,215 (5181-70400/P5200) 



14 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



to Appellants' claimed invention. Otherwise, Czerwinski cannot be said to teach the 
identical invention arranged as in Appellants' claims . Moreover, as discussed above, no 
combination of teachings in Czerwinski teaches Appellants' claimed invention. 

Appellants note that the Examiner has never provided any rebuttal to the 
above arguments in regard to claim 7. 

Second Ground of Rejection 

Claims 8, 24 and 40 stand finally rejected under 35 U.S.C. § 103(a) as being 
impatentable over Czerwinski in view of Vacon. Appellants traverse this rejection for at 
least the following reasons. Different groups of claims are addressed under their 
respective subheadings. 

Regarding claim 8, contrary to the Examiner's assertion, Czerwinski in view of 
Vacon fails to teach wherein the indication of the advertisement in the capability 
credential request message is a version of the advertisement edited to describe only the 
set of desired capabilities . As described herein above, Czerwinski does not teach the use 
of a capability credential request message that includes an indication of an advertisement. 
The Examiner cites a passage in Vacon that describes how network servers use multi-cast 
request messages to locate services that match a client's request. The Examiner is relying 
upon Vacon' s teaching that a server includes identification, by fimction, of the requested 
service in the multi-cast request message (Vacon column 2, lines 1-5). However, when a 
server is sending a multi-cast request message including a desired service, it is not 
sending a capability credential request message. Instead, it is a multi-cast request 
message to which all services providing the desired service reply (Vacon, column 5, lines 
23-51). 

Further, a server in Vacon' s system does not include a version of an 
advertisement edited to describe only a set of desired capabilities in the multi-cast request 
message. Instead, Vacon clearly teaches that a server saves only the network address of 
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the service and discards the remainder of the service advertisement (Vacon, column 2, 
lines 34-46). Thus, xmder Vacon, the service advertisement is not even saved, much less 
edited to describe only a set of desired capabilities and included in a capability credential 
request message. 

Additionally, the Examiner's proposed combination of Czerwinski in view of 
Vacon would not result in a system that includes wherein the indication of the 
advertisement in the capability credential request message is a version of the 
advertisement edited to describe only the set of desired capabilities. In fact, such a 
combination would result in a system where the SDS servers taught by Czerwinski send 
multi-cast request messages, including an indication of the desired service, to find 
services that match a client's needs. However, since, as noted above, neither Czerwinski 
nor Vacon, discloses a capability credential request message including an indication of 
an advertisement for a service, a combination of Czerwinski and Vacon would also not 
include a capability credential request message including an indication of an 
advertisement, wherein the indication of the advertisement is a version of the 
advertisement edited to described only the set of desired capabilities. Appellants note 
that the Examiner has failed to provide any rebuttal to Appellants' arguments 
regarding claim 8. 

Third Ground of Rejection 

Claims 14, 15, 30 and 46 stand finally rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Czerwinski in view of Johnson. Appellants traverse this rejection for 
at least the reasons given above regarding their respective independent claims. 

VIIL CONCLUSION 

For the foregoing reasons, it is submitted that the Examiner's rejection of claims 
1-47 was erroneous, and reversal thereof is respectfiiUy requested. 
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The Commissioner is authorized to charge the appeal brief fee of $500.00 and any 
other fees that may be due to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit 
Account No. 501 505/5 181-70400/RCK. This Appeal Brief is submitted with a return 
receipt postcard. 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 
Attorney for Appellants 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

(512) 853-8850 

Date: July 29, 2005 
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IX. CLAIMS APPENDIX 



The claims on appeal are as follows. 

1. A method for accessing a service in a distributed computing environment, 
comprising: 

a client locating a first service within the distributed computing environment; 

the client requesting a capability credential to allow the client access to a portion 
of the first service's capabilities, wherein said requesting a capability 
credential comprises the client indicating a set of desired capabilities; 

the client receiving said capability credential, wherein said capability credential 
indicates that the client has the right to use said portion of the first 
service's capabilities; and 

the client using said capability credential to access one or more of said portion of 
the first service's capabilities. 

2. The method as recited in claim 1, wherein said requesting a capability 
credential comprises the client sending a capability credential request message, wherein 
said capability credential request message comprises an identification of said first service 
and an indication of the set of desired capabilities. 

3. The method as recited in claim 2, wherein said identification of said first 
service comprises a Universal Unique Identifier (UUDD). 

4. The method as recited in claim 2, wherein said capability credential 
request message is formatted in extensible Markup Language (XML). 
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5. The method as recited in claim 2, further comprising: 

the cUent receiving an advertisement for the first service, wherein said 
^ advertisement describes the portion of the first service's capabilities; and 

wherein said indication of the set of desired capabilities comprises an indication 
of said advertisement. 

6. The method as recited in claim 5, wherein said indication of said 
advertisement is said advertisement itself 

7. The method as recited in claim 5, wherein said indication of said 
advertisement is a Uniform Resource Identifier (URI) to said advertisement. 

8. The method as recited in claim 5, wherein said advertisement describes all 
of the first service's capabilities, and wherein said indication of said advertisement in said 
capability credential request message is a version of said advertisement edited to describe 
only said set of desired capabilities. 

9. The method as recited in claim 5, wherein said advertisement is a 
protected advertisement that describes the first service's capabilities but does not provide 
an interface to the first service's capabilities. 

1 0. The method as recited in claim 1 , further comprising: 

the client receiving a protected advertisement for the first service, wherein said 
protected advertisement indicates an address for sending said capability 
credential request message to; and 
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wherein said requesting a capability credential comprises the client sending a 
capability credential request message to said address indicated in said 
protected advertisement. 

11. The method as recited in claim 10, wherein said address indicated in said 
protected advertisement is for an authentication service, wherein said sending a capability 
credential request message comprises sending said capability credential request message 
to said authentication service, the method further comprising the authentication service 
sending a credential request response message to the client in response to said capability 
credential request message. 

12. The method as recited in claim 11, wherein said credential request 
response message includes said capability credential, wherein said receiving said 
capability credential comprises receiving said capability credential from said 
authentication service in said credential request response message. 

1 3 . The method as recited in claim 1 , further comprising: 

the client receiving a protected advertisement for the first service, wherein said 
protected advertisement indicates an authentication service; and 

wherein said requesting a capability credential comprises the client requesting a 
capability credential from said authentication service. 

14. The method as recited in claim 13, the method further comprising: 

said authentication service determining a level of the first service's capabilities 
that the client is authorized to use; 

said authentication service generating said capability credential according to said 
level and said set of desired capabilities; and 
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said authentication service sending said capability credential to the client, wherein 
said portion of the first service's capabilities that said capability credential 
indicates that the client has a right to use is no more than said set of 
desired capabilities. 

15. The method as recited in claim 14, wherein said portion of the first 
service's capabilities that said capability credential indicates that the client has a right to 
use is the lesser of said level of the first service's capabilities that the client is authorized 
to use and said set of desired capabilities. 

16. The method as recited in claim 1, wherein said using said capability 
credential to access one or more of said portion of the first services capabilities comprises 
the client sending a message to the first service to access a first capability, wherein the 
message includes said capability credential, the method fiirther comprising the first 
service authenticating said capability credential received in the message to verify that the 
client has the right to use said first capability. 

17. A client device, comprising: 

a connection to a distributed computing environment; 

an interface coupled to said connection and configured to locate a first service 
within the distributed computing environment; 

wherein the interface is fixrther configured to request over the connection a 
capability credential for a set of desired capabilities to allow the client on 
the client device access to a portion of the first service's capabilities; 

wherein the interface is further configured to receive over the connection said 
capability credential, wherein said capability credential indicates that the 
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client has the right to use said portion of the first service's capabilities; 
and 

wherein the interface is further configured to use said capability credential to 
access one or more of said portion of the first service's capabilities. 

18. The cHent device as recited in claim 17, wherein the interface is 
configured to request a capability credential by sending a capability credential request 
message, wherein said capability credential request message comprises an identification 
of said first service and an indication of the set of desired capabiUties. 

19. The client device as recited in claim 18, wherein said identification of said 
first service comprises a Universal Unique Identifier (UUID). 

20. The client device as recited in claim 18, wherein said capability credential 
request message is formatted in extensible Markup Language (XML). 

21. The client device as recited in claim 18, wherein the interface is further 
configured to receive an advertisement for the first service, wherein said advertisement 
describes the portion of the first service's capabilities, and wherein said indication of the 
set of desired capabilities comprises an indication of said advertisement. 

22. The client device as recited in claim 21, wherein said indication of said 
advertisement is said advertisement itself 

23. The client device as recited in claim 22, wherein said indication of said 
advertisement is a Uniform Resource Identifier (URI) to said advertisement. 

24. The client device as recited in claim 21, wherein said advertisement 
describes all of the first service's capabilities, and wherein said indication of said 
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advertisement in said capability credential request message is a version of said 
advertisement edited to describe only said set of desired capabilities. 

25. The client device as recited in claim 21, wherein said advertisement is a 
protected advertisement that describes the first service's capabilities but does not provide 
an interface to the first service's capabilities. 

26. The client device as recited in claim 17, vv^herein the interface is further 
configured to receive a protected advertisement for the first service, wherein said 
protected advertisement indicates an address for sending said capability credential request 
message to, and wherein the interface is configured to request a capability credential by 
sending a capability credential request message to said address indicated in said protected 
advertisement. 

27. The client device as recited in claim 26, wherein said address indicated in 
said protected advertisement is for an authentication service, wherein said sending a 
capability credential request message comprises sending said capability credential request 
message to said authentication service. 

28. The client device as recited in claim 27, wherein the interface is 
configured to receive said capability credential from said authentication service in a 
credential request response message. 

29. The client device as recited in claim 17, wherein the interface is further 
configure to: 

receive a protected advertisement for the first service, wherein said protected 
advertisement indicates an authentication service; and 

request a capability credential by requesting a capability credential from said 
authentication service. 



09/653,2 1 5 (5 1 8 1 -70400/P5200) 



23 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



30. The client device as recited in claim 29, wherein said portion of the first 
service's capabilities that said capability credential indicates that the client has a right to 
use is the lesser of said level of the first service's capabilities that the client is authorized 
to use and said set of desired capabilities. 

31. The client device as recited in claim 17, wherein the interface is 
configured to use said capability credential to access one or more of said portion of the 
first services capabilities for said client by sending a message to the first service to access 
a first capability, wherein the message includes said capability credential so that the first 
service may authenticate said capability credential received in the message to verify that 
the client has the right to use said first capability. 

32. The client device as recited in claim 17, wherein said interface comprises 
one or more processes executable on a processor within the client device. 

33. A carrier medium comprising program instructions, wherein the program 
instructions are computer-executable on a cUent device to implement: 

locating a first service within the distributed computing environment; 

requesting a capability credential to allow a cUent on the client device access to a 
portion of the first service's capabilities, wherein said requesting a 
capability credential comprises the client indicating a set of desired 
capabilities; 

receiving said capability credential, wherein said capability credential indicates 
that the client has the right to use said portion of the first service's 
capabilities; and 
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using said capability credential to access one or more of said portion of the first 
service's capabilities. 

34. The carrier medium as recited in claim 33, wherein said requesting a 
capability credential comprises the client sending a capability credential request message, 
wherein said capability credential request message comprises an identification of said 
first service and an indication of the set of desired capabilities. 

35. The carrier medium as recited in claim 34, wherein said identification of 
said first service comprises a Universal Unique Identifier (UUID). 

36. The carrier medium as recited in claim 34, wherein said capability 
credential request message is formatted in extensible Markup Language (XML). 

37. The carrier medium as recited in claim 34, wherein the program 
instructions are computer-executable on the client device to fiirther implement: 

receiving an advertisement for the first service, wherein said advertisement 
describes the portion of the first service's capabilities; and 

wherein said indication of the set of desired capabilities comprises an indication 
of said advertisement. 

38. The carrier medium as recited in claim 37, wherein said indication of said 
advertisement is said advertisement itself 

39. The carrier medium as recited in claim 37, wherein said indication of said 
advertisement is a Uniform Resource Identifier (URI) to said advertisement. 

40. The carrier medium as recited in claim 37, wherein said advertisement 
describes all of the first service's capabilities, and wherein said indication of said 
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advertisement in said capability credential request message is a version of said 
advertisement edited to describe only said set of desired capabilities. 

41. The carrier medium as recited in claim 37, wherein said advertisement is a 
protected advertisement that describes the first service's capabilities but does not provide 
an interface to the first service's capabilities. 

42. The carrier medium as recited in claim 33, wherein the program 
instructions are computer-executable on the client device to further implement: 

receiving a protected advertisement for the first service, wherein said protected 
advertisement indicates an address for sending said capability credential 
request message to; and 

wherein said requesting a capability credential comprises the client sending a 
capability credential request message to said address indicated in said 
protected advertisement. 

43. The carrier medium as recited in claim 42, wherein said address indicated 
in said protected advertisement is for an authentication service, wherein said sending a 
capability credential request message comprises sending said capability credential request 
message to said authentication service. 

44. The carrier medium as recited in claim 43, wherein said receiving said 
capability credential comprises receiving said capability credential from said 
authentication service in a credential request response message. 

45. The carrier medium as recited in claim 33, wherein the program 
instructions are computer-executable on the client device to further implement: 
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receiving a protected advertisement for the first service, wherein said protected 
advertisement indicates an authentication service; and 

wherein said requesting a capabiUty credential comprises the client requesting a 
capability credential fi^om said authentication service. 

46. The carrier medium as recited in claim 45, wherein said portion of the first 
service's capabilities that said capability credential indicates that the client has a right to 
use is the lesser of said level of the first service's capabilities that the client is authorized 
to use and said set of desired capabilities. 

47. The carrier medium as recited in claim 33, wherein said using said 
capability credential to access one or more of said portion of the first services capabilities 
comprises the client sending a message to the first service to access a first capability, 
wherein the message includes said capability credential so that the first service may 
authenticate said capability credential received in the message to verify that the client has 
the right to use said first capability. 
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X. EVIDENCE APPENDIX 

No evidence submitted under 37 CFR §§ 1.130, 1.131 or 1.132 or otherwise 
entered by the Examiner is relied upon in this appeal. 
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XI. RELATED PROCEEDINGS APPENDIX 

There are no related proceedings. 
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